Using a force-based paradigm for managing operational fulfillment

ABSTRACT

Provided are techniques for defining a fulfillment path solution (FPS) comprising items undergoing an operational fulfillment process (OFP); wherein the FPS is associated with milestones to be fulfilled by the items as the items travel the OFP. Each milestone exerts a resistive force on each item. Calculating a plurality of sums, each sum corresponding to a particular item and each sum a total of all resistive forces exerted on the corresponding item by each of the milestones, wherein an item with a deadline closer to the current time is set to a higher resistive force than an item with a deadline farther from the current time; and increasing each resistive force on each item as a corresponding deadline approaches each item; wherein a higher sum indicates a need for more immediate attention.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation and claims the benefit of thefiling date of an application entitled, “Using a Force-Based Paradigmfor Managing Operational Fulfillment” Ser. No. 13/538,520, filed Jun.29, 2012, assigned to the assignee of the present application, andherein incorporated by reference.

FIELD OF DISCLOSURE

The claimed subject matter relates generally to operation fulfillmentand, more specifically, to intuitive and easy to use techniques thatfacilitate an operational fulfillment process.

SUMMARY

Provided are techniques that facilitate operational fulfillment in amanner that is intuitive and easy to use. Operational fulfillmentaddresses issues that arise with respect to the delivery, or“provisioning,” of resources on time and with a promised measure ofquality. In business enterprises, collaboration concerning workactivities to enable process fulfillment is common. Process readinessand enablement teams may monitor and manage operations of businessactivity to make sure any particular business is enabled and fulfilled.Business processes such as, but not limited to, order fulfillment,product announcement, service request fulfillment, and so on typicallytouch multiple organizations and applications within an enterprise.Milestones and exception alerting may be spread over many internalsystems and organizations. Existing technologies like Business ActivityMonitoring (BAM), Business Process management (BPM), and Business EventProcessing (BEP) collaborate to provide the desired solutions. However,in nearly all deployments of these technologies, extensive tailoring tospecific enterprises is required. Due to the high degrees of systemintegration required for initial deployment, many enterprises useexperts that specialize in BAM, BPM, and BEP to implement solutions.This makes these solutions very costly with a long time to value.

Provided are techniques for defining a fulfillment path solution (FPS)comprising a plurality of items undergoing an operational fulfillmentprocess (OFP); wherein the FPS is associated with a plurality ofmilestones to be fulfilled by the plurality of items as the items travelthe OFP; and wherein each milestone of the plurality of milestonesexerts a resistive force on each item of the plurality of items;calculating a plurality of sums, each sum corresponding to a particularitem and each sum a total of all resistive forces exerted on thecorresponding item by each of the milestones; the calculating of eachresistive force, comprising: setting an initial resistive force, withrespect to each item, based upon a difference between a deadlineassociated with the milestone and the item, wherein an item with adeadline closer to the current time is set to a higher resistive forcethan an item with a deadline farther from the current time; andincreasing each resistive force on each item as a corresponding deadlineapproaches each item; wherein a higher sum corresponding to a first itemand a lower sum corresponding to a second item indicates a need for moreimmediate attention to the first item than the second item; andtransmitting a notification event based upon the plurality of sums andcorresponding items to indicate which items require more immediateattention.

This summary is not intended as a comprehensive description of theclaimed subject matter but, rather, is intended to provide a briefoverview of some of the functionality associated therewith. Othersystems, methods, functionality, features and advantages of the claimedsubject matter will be or will become apparent to one with skill in theart upon examination of the following figures and detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the claimed subject matter can be obtainedwhen the following detailed description of the disclosed embodiments isconsidered in conjunction with the following figures.

FIG. 1 is a computing architecture that may implement the disclosedtechniques.

FIG. 2 is an illustration of a Force-Based Build-time Services (FBBS),first introduced in FIG. 1, which may implement aspects of the claimedsubject matter.

FIG. 3 is an illustration of a Force-Based Runtime System (FBRS), firstintroduced in FIG. 1, which may implement aspects of the claimed subjectmatter.

FIG. 4 is an example of a Force-Based ItemObject that may be employed toimplement the claimed subject matter.

FIG. 5 is a flowchart of an Initialize Fulfillment Path Solution (FPS)process that may implement aspects of the claimed subject matter.

FIG. 6 is a flowchart of an Update FPS process that may implementaspects of the claimed subject matter.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational actions to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

As the Inventors herein have realized, business processes such, but notlimited to, order fulfillment, product announcement, service requestfulfillment, typically touch multiple organizations and applicationswithin an enterprise, resulting in an arduous and time-consuming task ofcapturing, managing and reporting an end-to-end view of products and/orservices being fulfilled.

Current solutions for the management of operations fulfillment, such asBusiness Activity Monitoring (BAM), Business Process Management (BPM)and Business EVENT Processing (BEP), are costly, inflexible, complex andmay require extensive customization by specialized experts. In otherwords, with respect to existing technologies, extensive tailoring isrequired to employ a solution within a specific enterprise. One goal ofthe disclosed technology is to describe a new paradigm and associatedtools that may be employed to simplify operational fulfillment,empowering business users to easily create, customize, deploy and manageoperational fulfillment solutions that are intuitive and easy to use.

The herein disclosed new paradigm involves a “force-based” approach inwhich items undergoing fulfillment each have an affinity towards afulfillment target and barriers exert a resistive force on the items. A“barrier” is a milestone on a timeline with completion conditions thatthe item must complete or satisfy in order to advance its fulfillment.Once all milestones (barriers) are fulfilled, the item will befulfilled. An “item” is an entity undergoing a fulfillment process,including, but not limited, to, parts, products, service requests, andso on. An item is associated with a fulfillment path. A fulfillment pathincludes milestones, i.e. “barriers,” that an item must meet to achievea fulfillment goal. The disclosed technology includes multipleuser-specified fulfillment paths, including, but not limited to, orderfulfillment, service request fulfillment, new product announcement andso on. An item is assigned to a fulfillment path in conjunction with anannouncement event.

Iwo different types of events are “announcement” events and “status”events. Announcement events notify a force-based runtime system (FBRS)(see 148, FIGS. 1 and 3) that a fulfillment path solution (FPS) is to beinitialized (see 250, FIG. 5). In other words, an announcement eventpresents a goal to be fulfilled and is used to associate items to aspecific fulfillment path that correspond to the goal. In addition, anannouncement event associates specific items to be fulfilled (managed)to the initialized fulfillment path instance. Status events relay thestatus of items and are employed by barriers to determine if barriers,or “milestones,” have been completed. A milestone comprises, but is notlimited to, an event and a deadline fur the event to happen. Forexample, in a product delivery type fulfillment path, a particularproduct, i.e. “item,” must be packaged for mailing, i.e., “event,” by aspecific date, i.e. “deadline,” to meet the goal of the FPS. Statusevents are also employed to report progress of fulfillment paths.

The disclosed technology employs a force-based paradigm to manage a FPS.In other words, a FPS comprises milestones that exert a force on itemsin the FPS. As an item approaches the deadline, the force on the itemincreases. Other factors such as, but not limited to, capacity may alsoaffect the force on a particular item. For example, more force may beexerted on the particular product with respect to the packaging deadlineif there are more of a particular item to process.

Turning now to the figures, FIG. 1 is a computing architecture 100 thatmay implement the disclosed techniques. A force-based build system(FBBS) server 102 includes a central processing unit (CPU) 104, coupledto a monitor 106, a keyboard 108 and a pointing device, or “mouse,” 110,which together facilitate human interaction with computing system 100and FBBS server 102. Also included in FBBS server 102 and attached toCPU 104 is a computer-readable storage medium (CRSM) 112, which mayeither be incorporated into FBBS server 102 i.e. an internal device, orattached externally to CPU 104 by means of various, commonly availableconnection devices such as but not limited to, a universal serial bus(USB) port (not shown). CRSM 112 is illustrated storing an operatingsystem (OS) 114 and a FBBS component, or simply FBBS 116. FBBS 116 isdescribed in more detail below in conjunction with FIGS. 2-6.

FBBS server 102 and CPU 104 are connected to a Local Area Network (LAN)120, which provides connectivity to the Internet 122. Two clientsystems, i.e. a CS_(—)1 124 and a CS_(—)2 126 are communicativelycoupled to LAN 120 and a client system, i.e. CS_(—)3 128 is coupled toInternet 122. Although in this example, FBBS server 102, CS_(—)1 124,CS_(—)2 126 and CS_(—)3 128 are communicatively coupled via one or bothLAN 120 and the Internet 122, they could also be coupled through anynumber of communication mediums such as, but not limited to, a wide areanetwork (WAN) (not shown), direct wire and wireless systems.

Also coupled to the Internet 122 is a force-based runtime system (FBRS)server 132. Like FBBS server 102, FBRS server 132 includes a CPU 134, amonitor 136, a keyboard 138, a mouse 140 and a CRSM 142. CRSM 142 isillustrated storing an OS 144 and a FBRS component, or simply FBRS 148.FBRS 148 is described in more detail below in conjunction with FIGS.2-6. Further, it should be noted there are many possible computingsystem configurations, of which computing system 100 is only one simpleexample. The particular components of FIG. 1 are used as examplesthroughout the remainder of the Description.

FIG. 2 is an illustration of FBBS 116, first introduced in FIG. 1, whichmay implement aspects of the claimed subject matter. In this example,logic associated with FBBS 116 is stored in CRSM 112 (FIG. 1) andexecuted on one or more processors (not shown) of CPU 104 (FIG. 1) ofFBBS server 102 (FIG. 1).

A business administrator (BA) 150 employs a design center 152, which maybe implemented as a graphical user interface (GUI) (not shown) on FBBSserver 102. Design center 152 enables BA 150 is select previouslydesigned elements stored in a generic fulfillment path database, or“GFP,” 160. In this example, defined elements in GFP 160 include items162, events 164 and timeline/milestones 166. BA 150 may use eitherdefined or customized elements of GFP 160 to produce templates offulfillment paths (not shown), which are stored in a fulfillment pathlibrary (FPL) 170.

By modifying templates stored in FPL 170, BA 148 may generatefulfillment paths that are customized for specific situations. Suchcustomization typically involves the defining of generic elements ofitems 162, events 164 and timeline/milestones 166. For example, itemsand events may be given specific names and milestones may be named andassigned specific initial weights. Such customized fulfillment paths arestored in a fulfillment path solution library (FPSL) 180. Once aparticular fulfillment path has been customized for a specificsituation, a corresponding fulfillment path solution template (FPST)181-183 is transmitted to FBRS 118 (FIG. 1; see FIG. 3) via a deploymentpath 190. Deployment path 190 is simply one technique for transmittingFBSTs generated with FBBS 118 to FBRS 148 (FIG. 1) for implementation.For example, BA 150 may select a particular FBST 181-183, select a FBRSserver such as FBRS server 132 (FIG. 1) to which to deploy the selectedFBS(s) and hit a Deploy button (not shown) on a GUI (not shown) thatinvokes a web service (not shown) associated with a deployment manager(see 202, FIG. 3) to deploy the selected FBST(s) to the selected FBRSserver.

FIG. 3 is an illustration of Force-Based Runtime System (FBRS) 148,first introduced in FIG. 1, which may implement aspects of the claimedsubject matter. In this example, logic associated with FBRS 148 isstored in CRSM 142 (FIG. 1) and executed on one or more processors (notshown) of CPU 134 (FIG. 1) of FBRS server 132 (FIG. 1).

As described, above in conjunction with FIG. 2, a FPSTs 181-183 isdeployed to FBRS 148 via deployment path 190 (FIG. 2) to a deploymentmanager 202. Deployment manager 202 stores selected deployed instancesof FPSTs 181-183 in a deployed fulfillment path solutions (DFPS)library, or simply DFPS 204. In this example, deployed FPSTs areillustrated, i.e. a FPS_(—)1 211, a FPS_(—)2 212 and a FPS_(—)3 213.Each of FPSs 211-213 includes event items. For the sake of simplicity,only items associated with FPS_(—)1 211 are illustrated, i.e. an I_(—)1221, an I_(—)2 222 and an I_(—)3 213. In should be noted that in areal-world scenario, there may be many more FPSs with many more itemsbut for the sake of simplicity only a few of each are illustrated.

Events within the system managed by the disclosed technology originatefrom various event sources 230. In the following examples, two (2) typesof events are used: “announcement” events and “status” events. Asexplained in more detail below in conjunction with FIGS. 4-6, anannouncement event is employed to select a particular FPST 181-183 andinitialize a particular FPS such as FPSs 211-213. In other words, uponreceipt of an announcement event, an FPST 181-183 is selected thatcorresponds to the particular event and a specific FPS instance such asFPS 211-213 is initiated. In other words, FPSTs 181-183 are templatesthat represent particular types of business processes. When anannouncement event is received, the event is correlated to anappropriate template and a specific FPS 211-213 is generated. A statusevent is employed to update corresponding items 221-223 in FBS 211-213.Some examples of the source of a status event include, but are notlimited to, business processes, applications, databases (DBs), people,files and so on. In other words, any event within an organization thatmight affect a project timeline or milestone is a status event, e.g.completion of a business process or a particular module of anapplication or project, the addition or attrition or employees,collection of necessary data and a manager's approval of a particularevent.

In this example, an event 232 that originated from event source 230, istransmitted to an event manager 206. Event manager 206 storesinformation concerning event 232 in an events DB 208. Event manager 206also maintains an item DB 210 and correlates received events such asevent 232 to items in item DB 210. Based upon the correlation ofreceived events to particular item (any particular event 232 may impactmore than one item), event manager 206 updates FPSs such as FPS 211-213and corresponding instances 221-223 stored in deployed fulfillment pathsolutions 204. The updating of FPSs 211-213 and items 221-223 isexplained in more detail below in conjunction with FIGS. 4-6. Anotification manager 224 is responsible for the transmission, via aNotification Path 226, of reports to administrators of a particular OPFrelating to the progress.

FIG. 4 is an example of a Force-Based ItemObject (FBIO) 250 that may beemployed to implement the claimed subject matter. FBIO 250 includes atitle section 252, which merely states the name of object 250, i.e.“FBItemObject,” an attribute section 254, which contains memoryelements, or attributes, associated with FBIO memory object 250, and amethod section 256, which includes functions, or methods, that may beexecuted in conjunction with FBIO 250. It should be noted that theattributes and methods described are used for the purpose ofillustration only. Additional and/or different attributes and methodsmay be employed to implement the claimed subject matter.

Attribute section 252 includes an “fbIOID” attribute 258, a “date”attribute 260, an “FBSID” attribute 262, a “rForce” attribute 264, as“fForce” attribute 266, an “nForce” attribute 268 and an “attributes”attribute 270.

FbIOID attribute 258 is a variable of type FBIObjectID that contains areference to the particular instance of object 250. Each instance ofobject 250 has a unique value for attribute 258 that allows eachinstance to be uniquely identified. Instantiations of object 250 arestored in CRSM 112 (FIG. 1) in conjunction with both FBSBS 116 (FIGS. 1and 2) and FBSRS 118 (FIGS. 1 and 3). Date attribute 260 is a variableof type DateInfor that stores a reference to a particular time and datethat the corresponding instantiation object 250 was last updated. FPSIDattribute 262 is a variable of type FPSObjectID that stores a recordidentifying a specific FPS such as FSBs 211-213 that may be affected byan update to any particular instantiation of object 250. It should beunderstood that a particular event may affect multiple FPSs. In thatcase attribute 262 may be implemented as an array of attributes of typeFPSObjectID.

rForce attribute 264 is a variable of type array, or list, that storesthe various resistive forces associated with the particularinstantiation of FBIO 250. Specific forces stored in attribute 264 wouldtypically be of type Float or Integer. Typically, the total resistiveforces are exerted on the item by barriers and may be comprised ofmultiple components, each stored as an element of array 264 such as, butnot limited to, a deadline-based force component, a capacity-based, orworkload, force component, quality-based force components and so on.

The following equation is one example of an algorithm that may beemployed to calculate a deadline-based force component of rForce 264:

IF a milestone is not yet completed, then

Deadline Resistive force=K1/(T−t) when T>t;

Deadline Resistive Force=MaxF when t=T; and

Deadline Resistive force=MaxF+K2(t−T) when t>T;

where:

-   -   t is the current date/time timestamp;    -   T is the date/time timestamp of the corresponding milestone;    -   K1 and K2 are user-specified and configurable constants; and    -   MaxF is a configurable constant representing the maximum value        or the resistive force when t=T.        In the event that a corresponding milestone has been completed,        the Deadline Resistive force would typically=0.

A capacity-based force component may be calculated based upon factorssuch as workload capacity. For example, assume a team that completes acertain milestone can typically complete one hundred (100) items per dayon average. The capacity-based component of rForce 264 will thenincrease proportionally to the number of items associated with themilestone.

In addition, an element of item priority may enter these equations. Forexample, the resistive force on an item may be proportional to thepriority of the item such as, Deadline Resistive force=P*(K1/(T−t) whenT>t and so on, where P a priority value assigned to the item. In such acase, an item's priority can be thought of as a weight such that aheavier weight produces a larger resistive reaction when it collideswith other objects. Further, items associated with larger resistiveforces would require more immediate attention than items with less as alarger resistance indicates that an item may be approaching or hasmissed a deadline.

fForce attribute 266 is a variable of type Array, or list, that storesthe various affinity-based forces associated with a particularinstantiation a FBItemObject 250. An affinity-based force measures thecorresponding item's affinity towards fulfillment such as the importancethat the item achieves a target on time. For example, an item with alarge fForce 266 may encounter higher resistive forces from a barrier tohighlight the importance and a need for attention if the barrier is notremoved on time.

nForce attribute 268 represents a net force, or combination of rForce266 and fForce 268. As such, nForce 268 may also simply be calculatedfrom rForce 266 and fForce 268 when needed. iAttributes 270 is avariable of type Array that stores attribute-value pairs that representthe item. Examples include, but are not limited to, name, description,part number and so on.

Method section 256 of object 250 includes two exemplary functions, ormethods. Only three methods are illustrated for the sake of simplicity.Those with skill in the programming arts should appreciate that anobject such as object 250 would typically include many additionalmethods including, but not limited to, constructors, destructors, andmethods to set and get values for various attributes.

An “updateItem” method 272 is called to update the values stored in oneor more instances of a FBItemObject 250. In this example, method 272 iscalled with one parameter: “FBIobject,” a variable of type Array thatstores the FBIobjects 250, identified by the value stored in thecorresponding fbIOID 258 and including any new values for attributes260, 262, 264, 266, 268 and 270. An updateForce method 274 is called toupdate the values of rForce 264, fForce 266 and nForce 268. Method 274is called with two parameters a fID parameter of type Integer that isused to identified the specific attribute 264, 266 or 268 to be updatedand a newForce attribute of type integer that stored the new value ofthe attribute 264, 266 or 268 to be updated. In addition, method 274performs calculations to update forces other than the identified forcebased upon the update. For example, an update to either rForce 264 orfForce 266 would necessitate an update to nForce 268.

A “getResistence” method 276 is called to get a current value for theresistance on the corresponding FBItemObject 250. Method 276 is calledwithout parameters and returns art Integer that represents the currentresistance. The current resistance is calculated based upon the forcevalues 264, 266 and 268 and parameters that determine the relative valuedifferent forces are given with respect to each other.

It should be understood that FBIO object 250 is only one example of amemory object that may be used to implement the claimed subject matter.Other memory objects with fewer, more and/or different attributes andmethods may be employed. In addition, there are many was other thanemploying object 250 to implement the functionality and data storage ofthe claimed subject matter. For example, the claimed subject matter maybe implemented by means of a computer program in conjunction with arelational database.

FIG. 5 is a flowchart of an Initialize FPS process 250 that mayimplement aspects of the claimed subject matter. In this example, logicassociated with process 250 is stored on CRSM 142 (FIG. 1) and executedon one or more processors (not shown) of CPU 134 (FIG. 1) of FBRS server132 (FIG. 1) in conjunction with FBRS 148 (FIGS. 1 and 3).

Process 250 starts in a “Begin Initialize FPS” block 252 and proceedsimmediately to a “Receive Announcement Event” block 254. Duringprocessing associated with block 254, an announce event is received atevent manager 296 (FIG. 3) of FBRS 148. As explained, an announcementevent presents a goal to be fulfilled and is used to associate items toa specific fulfillment path that correspond to the goal. Duringprocessing associated with a “Correlate to FPST” block 256, a specificFPST that corresponds to the goal declared in the announcement eventreceived during processing associated with block 254 is selected fromthe possible FPST(s). As explained above in conjunction with FIG. 2, BA150 defines various templates for FPSs that are stored in FPSL 180 anddeployed via deployment path 190. The announcement event received duringprocessing associated with block 254 is parsed to determine theparticular type of FPS, defined by BA 150 employing FBBS 116 (FIGS. 1and 2), that is appropriate. Different types of FPSTs may include, butare not limited to, FPST specifically designed to represent orderfulfillment, product announcement and service request fulfillmentscenarios.

During processing associated with a “Generate FPS Instance” block 258, aspecific instantiation of an FPS is generated using the FPST selectedduring processing associated with block 254. The selection is made basedupon information included with the announcement event. In the followingexample, FPS 211 is used for illustrative purposes. During processingassociated with an “Assign Items & Specify Dates” block 260, specificitems and corresponding deadlines are assigned to FPS 211. In addition,a fulfillment target date is assigned to FPS 211. This fulfillmenttarget date, which is specified in the announcement event, makes FPS 211unique. In this example, the assigned items, which are also specified inthe announcement event, are I_(—)1 221, I_(—)2 222 and I_(—)3 223. Forexample, if FPS 211 is an order fulfillment scenario, I_(—)1 221 mayrepresent that the product is ready for shipment, I_(—)2 222 mayrepresent the order has been packaged for shipment and I_(—)3 223 mayrepresent the package has been delivered to a delivery service. Itshould be noted that often deadlines are calculated in a reverse orderfrom the necessary deadline for completion of each item 221-223. Forexample, if a date has been specified for delivery of the product to acustomer, I_(—)3 223 may have a deadline one day prior to an overnightdelivery service. In a similar fashion, if it takes one day to get apackage to the overnight service and one day to package a product,I_(—)2 222 may have an assigned deadline one day prior to the deadlinespecified in I_(—)3 223 and I_(—)1 221 may have an assigned deadline oneday prior to I_(—)2 222.

During processing associated with a “Calculate Farces an Items” block262, each item 221-223 has the corresponding forces (see 264, 266 and268, FIG. 4) calculated (see 274, FIG. 4). Once forces have beencalculated, during processing associated with an “Update Items” block264, each item 221-223 is updated with the values of parameters such as,but not limited to: 1) FPS ID; 2) a target date corresponding to theitem; and 3) net force.

During processing associated with a “Calculate Force on Items” block266, FPS 211 is updated based upon the values stored in each of thecorresponding items 221-223. The net resistive force on FPS 211 is thenthe sum of all the forces corresponding to all the barriers within items221-223. In this manner, not only can administrator evaluate theprogress associated with each goal as represented by FPSs 211-213 butmay also evaluate progress associated with individual items, orbarriers, associated with each FPS 211-213. Typically, the higher theresistive force calculated for any particular FPS or item, the moreattention is needed to meet both item and FPS deadlines. Finally,control proceeds to an “End Initialize FPS” block 269 during whichprocess 250 is complete.

FIG. 6 is a flowchart of an Update FPS process 300 that may implementaspects of the claimed subject matter. In this example, logic associatedwith process 300 is stored on CRSM 142 (FIG. 1) and executed on one ormore processors (not shown) of CPU 134 (FIG. 1) of FBRS server 132(FIG. 1) in conjunction with FBRS 148 (FIGS. 1 and 3).

Process 300 starts in a “Begin Update FPS” block 302 and proceedsimmediately to a “Receive Event” block 304. During processing associatedwith block 304, FBRS 148 receives an event, which in the followingexample is either a status event or to timing event. As explained above,a status event typically includes information about each item in acorresponding FPS (see 306) and may include, but is not limited to,factors employed by barriers to determine if milestones corresponding tobarriers have been completed, i.e. “completion conditions.” Statusevents may also be employed to report progress of fulfillment paths.

A timing event is by RBRS 148 generated at periodically, user-definedintervals. Since resistive force is a function of time and possiblyother independent variables, the resistive forces have to beperiodically calculated at times in addition to the receiving of astatus event. For example, a particular barrier may have a deadline and,as the deadline approaches, the force on the barrier would increase astime increases.

During processing associated with a “Status Event?” block 306, adetermination is made as to whether or not the event received duringprocessing associated with block 304 is a status event, with thealternative being a timing event. If so, control processed to a“Correlate to FPS(s)” block 308. During processing associated with block308, the status event received during processing associated with block304 is correlated to a particular FPS, which in the following example isFPS_(—)1 211 (FIG. 1). It should be noted that a particular event may berelevant to more than one FPS but for the sake of simplicity onlyFPS_(—)1 211 is used in this example.

Once either the event received during processing associated with block304 has been determined to be a timing event during processingassociated with block 306 or a status event has been correlated to a FPSduring processing associated with block 308, control proceeds to a“Calculate Forces Generated by Milestones on Barriers” block 310. Duringprocessing associated with block 310, the event received duringprocessing associated with block 304 is evaluated with respect to eachitem, which, when a status event is received are items 221-223, whichcorrespond to FPS_(—)1 211. It should be noted that in the event theevent received during processing associated with block 304 is a timingevent, all milestones in all FPS(s) 211-213 are reevaluated in light ofthe timing event. For each item corresponding FPS(s), the resistiveforces on the barriers are calculated. During processing associated witha “Transmit Forces to Items” block 312, the forces calculated duringprocessing associated with block 310 are transmitted to each barrier. Inother words, each item in the affected FPS(s) receives updates from eachother item.

During processing associated with an Update Items” block 314, the netforce (see 268, FIG. 4) of each item 221-223 is updated based upon themagnitude of the forces transmitted during processing associated withblock 312. Finally, during processing associated with an “End UpdateFPS” block 319, process 300 is complete.

In this manner, resistive forces on each item and FPS are a function oftime and possibly other independent variables. For example, a resistiveforce may increase as time increases and approaches a deadline. For thisreason, resistive forces may also be calculated at periodic user-definedintervals in addition to whenever a status event is received (see 304,FIG. 6). Like in FIG. 6, a periodic update event may be generated byFBRS 148 and transmitted to each barrier. Each barrier would thencalculate forces (see 310, FIG. 6). Transmit the calculated forces toeach other barrier (see 312, FIG. 6) and update based upon thetransmitted forces (see 314, FIG. 6).

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

We claim:
 1. A method, comprising: defining a fulfillment path solution(FPS) comprising a plurality of items undergoing an operationalfulfillment process (OFP); wherein the FPS is associated with aplurality of milestones to be fulfilled by the plurality of items as theitems travel the OFP; and wherein each milestone of the plurality ofmilestones exerts a resistive force on each item of the plurality ofitems; calculating a plurality of sums, each sum corresponding to aparticular item and each sum a total of all resistive forces exerted onthe corresponding item by each of the milestones; the calculating ofeach resistive force, comprising: setting an initial resistive force,with respect to each item, based upon a difference between a deadlineassociated with the milestone and the item, wherein an item with adeadline closer to the current time is set to a higher resistive forcethan an item with a deadline farther from the current time; andincreasing each resistive force on each item as a corresponding deadlineapproaches each item; wherein a higher sum corresponding to a first itemand a lower sum corresponding to a second item indicates a need for moreimmediate attention to the first item than the second item; andtransmitting a notification event based upon the plurality of sums andcorresponding items to indicate which items require more immediateattention.
 2. The method of claim 1, further comprising periodicallyupdating the resistive forces and the plurality of sums.
 3. The methodof claim 1, further comprising setting each resistive force on eachparticular item associated with a particular milestone to a value ofzero when a corresponding milestone is fulfilled for the particularitem.
 4. The method of claim 1, the calculating of each resistive forcefurther comprising: setting each resistive force to an initial valuebased upon a corresponding capacity in addition to the correspondingdeadline; increasing a resistive force in response to an increase in acorresponding capacity; and decreasing a resistive force in response toa decrease in a corresponding capacity.
 5. The method of claim 1,further comprising calculating a total resistive force corresponding tothe OFP, comprising summing the plurality of sums.
 6. The method ofclaim 1, further comprising ordering the items corresponding to thenotification event based upon the magnitude of the corresponding sums.